1. Field of the Invention
The present invention is related to a method, system, program, and data structures for maintaining metadata in a storage system.
2. Description of the Related Art
Computing systems often include one or more host computers (xe2x80x9chostsxe2x80x9d) for processing data and running application programs, direct access storage devices (DASDs) for storing data, and a storage controller for controlling the transfer of data between the hosts and the DASD. In addition to storing actual data, also known as user or customer data, the storage controller often maintains metadata which provides information on tracks or blocks of data in the DASD or in a cache of the storage controller. The storage controller processes the metadata during certain operations on the customer data represented by the metadata to improve the speed and efficiency of those requested operations. A track of metadata could include information on anywhere from a few hundred to a couple of thousand of user tracks to all tracks in a volume. The metadata may indicate the layout and format of a customer data track, as well as other information. Typically the rules for accessing metadata are less strict than for customer data because metadata can be rebuilt. Customer data, on the other hand, is often managed in a manner that does not tolerate any potential loss of updates as the updates are not as easily recoverable as metadata.
In operating systems that conform to the International Business Machines Corporation (xe2x80x9cIBMxe2x80x9d) Enterprise Systems Architecture (ESA) 360, 370, and 390 architectures, the storage controller, also referred to as a control unit or storage director, manages access to a storage space comprised of numerous hard disk drives connected in a loop architecture, otherwise referred to as a Direct Access Storage Device (DASD). In such systems, data may be stored in a Count-Key-Data (xe2x80x9cCKDxe2x80x9d) data format. FIG. 1 illustrates a prior art CKD track stored in a CKD device. A home address (HA) identifies the location of the track in the storage unit and its operational status. Following the home address (HA) are the records, R0 through Rn. Record zero (R0) contains either system or user data. Each following record, R1 through Rn, includes a count area that identifies the record and defines the lengths of the key and data areas. The key area of each record is optional and may be used by the programmer to identify the information in the data area record. The data area contains customer data. The number of records (R) that can be placed on a track depends on the length of the data areas of the records, and whether the records contain a key area, and the size of the gaps. Records may be of equal or unequal lengths.
In the prior art CKD systems, for each CKD track, there is a Track Format Descriptor (TFD), which is a four byte data structure providing metadata on the arrangement of the CKD records on the track. FIGS. 2a and 2b illustrates the prior art structure of a Track Format Descriptor (TFD) when the CKD track described by the metadata is in a regular format without and with keys, respectively. A CKD track that is regular format without keys is a CKD track where all records except Record Zero (R0) and the end of file record (EOF) have the same length data field, referred to in FIG. 1 as data area. The EOF record indicates the end of the CKD track and has a key length and a data length of zero. The flag byte includes bits, where one bit indicates whether the track format is regular, another bit indicates whether the track format is regular with keys, and a third flag indicates whether the track has an EOF record. The other flags may indicate other characteristics of the track format. The TFD further includes in both instances of FIGS. 2a and 2b a byte indicating the number of records in the tracks. Further, in the case of FIG. 2a where the CKD track is regular without keys, two bytes of the TFD indicates the data length of the data areas of each record. In the case of FIG. 2b where the CKD track is regular without keys, ten bits are used for the number of CKD cells per record and six bits are used for the number of fixed blocks per record. If the CKD track is irregular, such that the data areas have different lengths, then the two additional bytes have the number of sectors used by the track.
Moreover, in the prior art, a client or host requesting a CKD track is provided a Track Format Information (TFI) data structure that includes the TFD stored with the customer data and additional fields for the key length and data length of the CKD track. The TFI fields for the key length and data length are returned empty to requesting host. The host would update the key and data length fields in the TFI with appropriate values if the CKD track is regular format with keys. The host would return to the storage controller the update to the customer data along with an updated TFI structure indicating that the track is updated. The storage controller or other device managing Input/Output (I/O) requests to the CKD storage device would then remove the TFD structure from the received TFI to store in the storage system as the metadata for the track being updated. The TFI structure, along with the key and data lengths therein, is discarded. The TFD extracted from the TFI does not include any data on the key length of the CKD track, just a flag indicating whether the track is of regular format with keys.
Write data may be processed in two ways, as a cache fast write (CFW) or a DASD fast write (DFW). A cache fast write operation involves writing data to cache without writing a copy of the update to the non-volatile storage unit (NVS) and without staging the track into cache before writing to the storage unit. A DASD fast write operation writes data to the NVS as well as the cache. In the current art, for a CKD track whose format is regular without keys, a cache fast write can be performed because the storage controller can reconstruct the CKD track format in cache with the updated customer data because the CKD track has data areas of equal length and no keys. However, if the CKD track format is regular with keys, the TFD does not indicate the key length nor data length as shown in FIG. 2b, which is needed to build the CKD track in cache. Because the TFD metadata does not provide information on the key or data length, an update to a CKD track that is of regular format with keys cannot be done without staging the track to update into cache to determine the layout and build the updated CKD track in cache. Requiring the staging of the CKD track into cache to build the update track would offset the benefit of the cache fast write method. Currently the TFD does not include a sufficient number of bytes to indicate the data length and key length, thus requiring that the CKD track to update is staged into cache to determine the layout and build the track in cache, with the proper key and data length formats.
For these reasons, there is a need in the art for improved techniques for providing metadata for tracks, such as CKD tracks, to Input/Output (I/O) processing operations.
Provided are a method, system, program, and data structure for maintaining metadata in a storage system, wherein metadata provides information on customer data in the storage system. A first metadata structure includes a plurality of fields, each field having a field length and including information on a block of customer data. A second metadata structure is generated to include a same plurality of fields in the first metadata structure, each field having the same field length as in the first metadata structure, wherein both the first and second metadata structures provide metadata on a same block of customer data. Metadata is included in at least one field in the second metadata structure from at least one field in the first metadata structure. Metadata is included in at least one field in the second metadata structure that is not included in the first metadata structure.
In further implementations, not all of the metadata in the first metadata structure is included in the second metadata structure. Code is provided associating at least one metadata value capable of being included in the first metadata structure with the second metadata structure. A combination of the metadata included in the second metadata structure and the at least one metadata value associated with the second metadata structure comprises all the metadata included in the first metadata structure and additional metadata not maintained in the first metadata structure.
In certain implementations, one field in the second metadata structure includes metadata from one corresponding field in the first metadata structure.
Yet further, bits in the field in the second metadata structure including data from the corresponding field in the first metadata structure are used to store metadata from at least one other field in the first metadata structure.
In further implementations, a determination is made of a number of bits needed to store the metadata in the corresponding field in the first metadata structure. If the determined number of bits is less than the length of the field in the second metadata structure storing metadata from the corresponding field in the first metadata structure, then each bit in the field in the second metadata structure not needed to store the metadata from the corresponding field in the first metadata structure is used to store metadata from at least one other field in the first metadata structure.
In yet further implementations, the second metadata structure is stored in the storage system.
Still further, a determination may be made as to whether the first metadata structure indicates that the customer data represented by the metadata is in a specified format. The second metadata structure is generated and stored in the storage system if the customer data is in the specified format. The first metadata structure is stored in the storage system to provide metadata for the customer data if the customer data is not in the specified format.
With the described implementations, the second metadata structure is provided in certain instances to include more metadata than included in the already deployed first metadata structure to provide further information on the customer data. Further, in certain implementation, the customer data does not need to be staged into cache to complete an I/O operation if the metadata provided with the customer data comprises the second metadata structure. Whereas, if the metadata provided with the customer data comprises the first metadata structure, then the customer data is staged into cache to determine information on the customer data in order to complete the I/O operation.